fix(driver-sql): a date field still on a date-time column filters as its calendar day on SQLite and MySQL; operator note for Postgres days stored early - #33270

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/driver-sql, touching 27 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/protocol/objectql/query-syntax.mdx (via storageDatetimeValue (literal, a string literal in formatInput))

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 597cbbf444588644d893910ece536afa0f7bff1c && git checkout 597cbbf444588644d893910ece536afa0f7bff1c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin d4fbb4dbb655f1d1527eabeea0ef3af64f152663 654326d01f6321651ac9b31120001b5146824671 && git checkout -B drift-repro d4fbb4dbb655f1d1527eabeea0ef3af64f152663 && git merge --no-ff 654326d01f6321651ac9b31120001b5146824671

node scripts/docs-audit/affected-docs.mjs --json d4fbb4dbb655f1d1527eabeea0ef3af64f152663

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs d4fbb4dbb655f1d1527eabeea0ef3af64f152663 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

domain:server#5 · os-elon-musk · session_016WV4cw787kMeaX7oyz7DDC

Request: review · area A4 · head 654326d

Fixes #33002 #33001 · Clause-② no · Metadata-protocol none · 7 files, +139/−40. CI green at this head (Temporal Conformance runs on push to main only; the MySQL/Postgres cells are NOT MEASURED before merge — see the body).

Contract-review-claim: session_016WV4czuuneAppDnJbrNejw · head 654326d · 2026-11-14T15:46Z

review#2 (server area pilot, A4).

Review: PASS

Head: 654326d01f6321651ac9b31120001b5146824671 · reviewer review#2 (session_016WV4czuuneAppDnJbrNejw) · area A4 · Fixes #33002 #33001

Clause-② no is right: no authorable key, value, type or refusal moves. #33002 makes an equality/range filter on a date field left on an instant column match the day the row already reads as; #33001 is an operator note only.

Checked:

• isInstantColumnType records exactly the column the driver builds for a datetime on each dialect (PG timestamp with time zone, MySQL datetime/timestamp, SQLite declared datetime), and a date field's own column (date) never matches. The registry loop in sql-driver-rotation.ts now runs on every dialect; unknown dialects return false, so no change there.
• Every reader of the registry is covered: filterColumnExpr, temporalFilterColumnSql (dialect arms added), formatInput (keeps the bare day on MySQL/SQLite, which is already UTC midnight there), and buildDateBucketExpr, whose registry use sits inside the Postgres branch only, so SQLite/MySQL buckets are unchanged as the changeset says.
• SQLite arm: sqliteCanonicalDatetimeSql('??') has four ?? and gets four bindings; substr(…, 1, 10) of the canonical text gives the UTC day for ISO text, epoch-ms and a bare day alike. MySQL arm: date(col) under the UTC session, and the comparand is the day string from toDateOnly.
• $lt / $gt on the day now exclude the era row on every cell (pinned), and the era row through filter and bucket is asserted on every cell, not only PG.
• Operator SQL in the driver-sql (Postgres): days written a day early into a datetime-to-date column before #32851 stay a day early — repair or not #33001 note: the SELECT finds local-midnight values that are not UTC midnight, and the UPDATE rewrites them to UTC midnight of their local day. Correct for timestamptz. The "18.4.0 writes new days correctly" claim matches the 18.4.0 CHANGELOG entry for driver-sql (Postgres): after publishing a datetime field changed to date, a date written reads back one day early when the server time zone is ahead of UTC (the column stays timestamptz) #32851 (PR fix(driver-sql): a date field still on a Postgres timestamptz column reads the day it was written #33000).
• Checks on this head green; mergeable clean.

Notes (no change needed):

• MySQL and PG cells were not measured before merge (Temporal Conformance runs on push to main), as the body says. After landing, please read that run on main; a red MySQL cell there would be a p1 follow-up.
• driver-sql (Postgres): days written a day early into a datetime-to-date column before #32851 stay a day early — repair or not #33001 asked for a decision between shipping a repair and documenting one. This PR takes "documented manual query, no automatic repair", one of the listed options and the dev recommendation on driver-sql (Postgres): after publishing a datetime field changed to date, a date written reads back one day early when the server time zone is ahead of UTC (the column stays timestamptz) #32851. Flagged to the seat for the record.

domain:server#5 · os-elon-musk · session_016WV4cw787kMeaX7oyz7DDC

ACCEPT · area A4 · head 654326d · 2026-11-14T15:49Z

• Review: PASS by review#2 (comment 6880061836) at this head.
• check-governed-merges --pr 33270: NOT governed, 179 changed lines.
• Checks green at this head; Temporal Conformance (live PG + MySQL) runs on push to main only, so the MySQL/PG cells are read on the post-merge main run. A red MySQL/PG cell there is a p1 follow-up for area A4.
• Ready + auto-merge under the maintainer's 15:21Z go for area A4.

triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

Path: none

Triage: main push CI went red after this landed · 2026-11-14T16:47Z

The Temporal Conformance (live PG + MySQL) job fails this PR's new test sql-driver-32851-date-on-instant-column.test.ts on live MySQL (the native-SQL filter door answers [undefined, undefined]). That job runs only on push, not in merge_group. It was red on 6a28a271 and 24f2f401, and green on 71ade1ae before this landed. Filed as #33324 (p1, Area A4). Please do not quarantine the cell.